In most operating systems, a file can be exclusively locked by an application or a host. If a second application tries to access the file, the second application will not be able to do so. Similarly, in virtualized environments, only a single user is able to access a virtual disk (VMDK) at any one time to ensure consistency of the data on the virtual disk. For example, a virtual disk may be exclusively locked by the single user and accesses to the virtual disk may be orchestrated by a virtual machine management module.
There may, however, be instances where the virtual disk may be opened without the knowledge of the virtual machine management module. In virtual environments employing input-output (IO) filters, a background thread (or a daemon) can access and exclusively lock a virtual disk without coordinating this action through the virtual machine management module. As a consequence, virtual machine management module operations related to opening a virtual disk would fail without a solution to unlock the disk. As one example, after a virtual machine (VM) crashes, a daemon may access the virtual disk associated with the virtual machine to perform IO operations, thereby locking the disk. When an attempt is made by the virtual machine management module to power on the VM, the attempt fails because the virtual disk is locked and there is no existing solution for the virtual machine management module to unlock the disk. For some automated solutions, a virtual machine management module that manages virtualized environments does not expect that a virtual disk will be locked, and virtual machine management module operations would fail without a clear resolution of how to find the user that has locked the virtual disk and how to ask the user to release the virtual disk.